• ojb ve hibernate gibi tooların (framework mü demek lazım) yaptığı iş. naesne yonelik yazılımlarda ilişkisel veritabanına olan arayüz katmanını oluşturur. nesne modelini, veritabanı tablolarına bağlama*, nesneler arası ilişkileri, oop'nin "abstraction", "inheritance", "polymorphism" gibi kavramlarını modele bağımlı olarak vertabanı yapısına yansıtma metodolojisidir.
  • ror der ki,
    "so an orm layer maps tables to classes, rows to objects, and columns to attributes of those objects. class methods are used to perform table-level operations, and instance methods perform operations on the individual rows."

    mealen,
    tabloları sınıflara, satırları nesnelere, kolonları değişkenlere map etme* işlemidir.
    sınıf metodları tablo seviyesinde işlemleri, nesne metodları ise satır seviyesinde işlemleri yaparlar.
  • (bkz: ado net entity framework)
  • (bkz: codeigniter)
    (bkz: active record)
  • php icin;

    (bkz: doctrine)
    (bkz: propel)
  • turk yapimi olani icin (bkz: orman framework)
  • kullanımına çoğu zaman soğuk baktığım olay. lakin, bir proje open source olarak dağıtılacak, birden fazla veritabanı kullanılabilecek , yazım üzerinde bir yazılımcı ordusu çalışacaksa amenna. orm'nin yeri ve zamanı olsada genel olarak veritabanlarını özel olarak kullandığı veritabanını bilen, sql'den anlayan kişiler için gereksiz gibi gelmekde bana.

    hakkında rahatsız olduğum noktalar :

    * kolayca veritabanı değiştirme miti : malisef çoğu zaman don değiştirir gibi veritabanını değiştiremiyorsunuz. veritabanınızı değiştirmeyi düşünüyorsanız büyük ihtimalle tasarım hataları yüzünden performans sıkıntısı yaşıyorsunuzdur ve aslen hem veritabanında hemde kodda optimizasyon yapmanız gerekiyordur.

    * sorgular üzerinde optimizasyon yapabiliyorken, yarım sayfa sql kodunu sunucuya göndermek yerine prosedür yazabiliyorken ve bunun için ekstra bir kütüphaneye ihtiyaç duymuyorken , orm ile kulağı tersten gösterme durumu.

    * veritabanında kolayca değişiklik yapma miti : sql'e bulaşmamayım derken koda bulaşmanız gerekiyor.

    * transactionlarda kontrolün kaybedilebilmesi ihtimali.

    ilgili yazısında aslen sqle az çok giydirmiş olsada , derdimi anlatması açısından joel spolsky'den gelsin :

    the law of leaky abstractions
    http://www.joelonsoftware.com/…akyabstractions.html
  • (bkz: laravel)
  • veritabanı desenine normalizasyon yönünde baskı yaparlar. misal, composite primary key oluşturmak istemezsiniz çünkü ek uğraş gerektirir, ancak dağınık bir uygulamanız varsa mecbur kalabilirsiniz. ayrıca, normalizasyon seviyesi arttıkça da raporların hızı konusunda endişelenmeye başlarsınız.

    .net için en pürüzsüz* kullanılanı ado.net entity framework'tür. basit, hafif*, hızlı ve ücretsiz olanlar arasından telerik openaccess tercih sebebi olabilir.

    her şeye rağmen çok angaryadan kurtarır. bir de özellikle code-first ile modeli kafanızda daha rahat oturtmanızı sağlar.
  • basit bir proje üzerinde denediğim ve sql'e bağışıklık kazandığımdanmıdır bilinmez pekte geliştiriciyi kurtaran birşey gibi gelmedi bana, daha doğrusu hakikaten gerekli mi sorusunu sordurdu bana. halen stored procedure kullanımı benim için en geçerli ve sağlam yöntemdir.
hesabın var mı? giriş yap